I think I can make it so that there is one command that can toggle block and line comments,, then seperate commands for just block and line toggling, my proposed algorithm is:

if only one of single line token or block tokens exist, toggle that, else do the following:

• check if all selections are line commented
  • if they are then line toggle
• check if all selections are block toggled
  • if they are then line toggle
• check if all selections are single line
  • if they are then line toggle
  • should this check for block comments?
• else toggle block
  • could potentially also check and skip over already line commented code, but then block toggling would also do line toggling

I implemented the above, and then separated line comment toggling into it's own command that is under space+c+l

there is definitely ways to make block commenting smarter, for example comment a block if selection is surrounded by only whitespace and then comment token or uncomment block that is surrounded by other characters then whitespace in a selection(though I think this could actually extend the comment block maybe). This could be saved for future pr if this functionality is wanted.

This PR should now be ready for review, some things to note:

• selection isn't extended to encompass the comment, wasn't sure how or if I should do this
• keybindings should be chosen, I know some people wanted to switch to #, I don't have strong opinions about this both are great to me
• this is pretty much first rust stuff I have done, so if anything seems wrong please don't assume it's not you probably know better then me.
• this is breaking change to how comment toggling works
  Also want to thank everyone for all the work they have put into helix, using and contributing to it has been a joy
  (the doc failing seems to be based on a failed network call, shouldn't affect this pr)

Thanks for working on this! I think block comments are useful to have in particular for languages that do not have line comments.

I had this in my daily driver for a while and have some thoughts. I think automatically switching between line comments and block commenys based upon whether more then 1 char is selectes is nice to have but I found myself frustrated by this as a default.

For languages that support them I almost always want line comments because of the more granular control (comment ten lines, later uncomment only two of them or move some part of the comment elsewhere without having to add new commentnstsrt/end) so I would prefer to keep that as is.
However for languages that do not have line comments by default it should fall back to adding a block comment to every selected lime (same for <space>cl).

I think the automatic option is still useful but perhaphs as a secondary command (maybe mapped to C-C by default and people who prefer it the other way around can swap those two?).

If other people (@archseer whatdo you think?) prefer the default as in this PR I think its fine too as the I keybindings can be swappes in my config. I think the suggesting about using block comments as a line comment fallback should definitely be implement

Thanks for your input @pascalkuthe it's very helpful, and unless someone else objects I think I will implement it as the default. This seems simpler and more intuitive to the user, I don't have time today to implement this but it was in the back of my mind after I marked it for review so it shouldn't take me too long.

sorry for the wait on this I have been pretty busy, the new relevant changes are more inline with @pascalkuthe suggestions(if you have the time to take a look at the new behaviour that would be appreciated, I am sure you are pretty busy right now so it's totally okay if you don't do an actual review)

the key changes are summarized here:

• toggle comments always does a line comment or uses block as line fallback (this makes it much less of a breaking change)

• it only does a regular block comment when the selection is already block commented

• line comment and block comment now both fallback to each other if there token is not available for that language

  • this is a proper fallback in the case of line comments where it comments each line separately

whats left at this point is to add this to the docs and look into making some more meaningful tests

How will this affect the default "C-c" => toggle_comments binding?

Only effects if there is no line comment-token for a language(falls back to using the block comment tokens to comment each line instead)or if the whole selection is block commented other then that toggle_comments stays the same

@gabydd Is this ready for review?

Yep except it still needs the documentation, the one thing I am still unsure about is if we want to change how the config for block comments is to make it a map to easier add the token for continue comments, or do we think that can be a seperate option?

ok thanks for letting me know. I will think about that during review

Just fixed the merge conflicts I also squashed the pr to one commit so it's easier to rebase when there are conflicts if we want I can make one commit the code changes and the other the languages.toml changes

(Also closes #4009 but I can't link the issue because the GH UI is terribble)

This only fixes that for block comments, I didn't want to change the functionality of line comments in this pr

What we could do is for languages without a block comment token, when using the toggle_block_comments it would only add or remove from the start of the selection as if you had a block comment that was the line comment on the left and an empty string on the right

redundant_clone seems to have some false positives: rust-lang/rust-clippy#10577

Let's add some #[allow(clippy::redundant_clone)]s arround those for now with a reminder to check if we can remove them when the MSRV is bumped. Looks like the issue isn't solved yet so we might have to keep the allows around for a little while

Using this since last week and works great, thanks for putting this up!